---title: "Transcrição da Prova Teórica 1" matricula: "20243000884" nome: "Gabriel Pinheiro Rocha" disciplina: "Gestão de Projetos de Software (GPS)" avaliacao: "Prova Teórica 1" data: "19/10/2026" nota_total: 24.3 legibilidade_global: "96%" classificacao: "Alta Legibilidade (>= 90%)" observacoes_caligrafia: "Caligrafia cursiva impecável, redonda, uniforme, com excelente organização espacial e todas as questões respondidas com alto rigor técnico e profundidade." format: html: toc: true theme: cosmo pdf: documentclass: scrartcl papersize: a4 geometry: - margin=20mm --- # Avaliação Teórica 1 — Transcrição de Respostas ## Questão 1 — Ciclo de Vida e Fundamentos de Projetos * **Legibilidade da Questão:** 97% * **Gravidade de Leitura:** Nenhuma ### 1.1 Projeto vs. Operação * **Resposta Manuscrita:** > O professor agente é um projeto visto que seu desenvolvimento é temporário (possui início e fim), progressivo (feito de pouco em pouco), arriscado e incerto já que envolve um desenvolvimento voltado para criação e inovação com chances de não ser realizado completamente e corretamente. ### 1.2 Análise de Trade-off no Triângulo de Ferro * **Resposta Manuscrita:** > Uma alternativa seria reduzir o escopo do projeto focando no MVP e mantendo tempo e custo. Já outra alternativa seria aumentar os custos para aumento da equipe de forma a reduzir os atrasos sem alterar o escopo. ### 1.3 Ciclo de Vida do Projeto e Abordagem * **Resposta Manuscrita:** > O ciclo de vida adotado é voltado para o modelo ágil já que o tempo e os custos do projeto são definidos previamente (15 aulas com sprints de 2 semanas) enquanto o escopo pode ser variável. --- ## Questão 2 — Escopo, EAP e Gestão de Backlog * **Legibilidade da Questão:** 95% * **Gravidade de Leitura:** Nenhuma ### 2.1 Estrutura Analítica do Projeto (EAP) * **Diagrama / Elemento Visual:** ```text Documentação base do projeto | +-----------------------+-----------------------+ | | | Desenvolvimento Definição inicial Levantamento do Project Charter via ReadMe de Requisitos ``` * **Resposta Manuscrita:** > A EAP funciona como uma estrutura hierárquica e visual do projeto onde cada pacote de trabalho nos níveis mais baixos se transforma diretamente em Issues a serem resolvidas e entregues de forma que, juntando todas elas, o projeto inteiro esteja contemplado. ### 2.2 Especificação de Issues de Backlog e Estimativas * **Resposta Manuscrita:** > Título: Desenvolvimento do Project Charter. > Descrição: Deve ser escrito um termo de abertura contendo a justificativa e plano inicial do projeto. > Critério: Deve possuir business case, requisitos de alto nível, premissas e restrições e objetivos SMART. > Estimativa de tempo/esforço: Probabilística via PERT considerando tempos otimistas e pessimistas em relação à entrevista com o cliente. > > Título: Levantamento de requisitos. > Estimativa de tempo: Menor que a anterior visto que a entrevista já estará feita e faltará apenas categorizar os requisitos. ### 2.3 Milestones vs. Sprints no Modelo Ágil * **Resposta Manuscrita:** > Milestones são tempos limites pré estabelecidos de prazo de entrega enquanto sprints se referem mais ao tempo usado e gerenciado pela equipe para o desenvolvimento do projeto. Milestones não necessariamente substituem sprints sendo ideal que haja a aplicação de ambos em conjunto. Em softwares tradicionais sem prazos bem definidos. --- ## Questão 3 — Qualidade e Engenharia de Software com IA * **Legibilidade da Questão:** 96% * **Gravidade de Leitura:** Nenhuma ### 3.1 Definição de Pronto (DoD) e Pipelines de CI/CD * **Resposta Manuscrita:** > Definição de Pronto (DoD) é um conjunto de requisitos mínimos que cada entrega deve atender a fim de garantir padronização e qualidade. Tal conceito se relaciona com CI/CD pois sem os testes de avaliação adequados não é possível verificar corretamente a qualidade da entrega e, consequentemente, não se pode classificar tal entrega como "pronta". ### 3.2 Custo da Qualidade (CoQ) * **Resposta Manuscrita:** > (a) Custo de avaliação, (b) custo de avaliação, (c) falha interna, (d) falha externa. > O custo mais alto é o de falha externa pois este acontece no momento de deploy do produto, ou seja, já com o consumidor final podendo acarretar em desconfiança e até processos. Já os outros possuem custos mais baixos pois acontecem na fase de produção, ou seja, de forma interna com possibilidade de correções sem envolver o usuário final. ### 3.3 Heurística 1:10:100 e Testes em Software com IA * **Resposta Manuscrita:** > A regra 1:10:100 diz que corrigir falhas encontradas antes de escrever código tem custo 1, corrigir falhas encontradas na fase de avaliação e testes tem custo 10 e corrigir falhas encontradas já na mão dos clientes tem custo 100. Através de tal regra, fica evidente que a realização de testes para detectar falhas antes do problema chegar no cliente é fundamental para evitar custos corretivos até 10 vezes maiores do que se corrigidos em fase de avaliação. Entretanto, em projetos com IA é importante entender que nem sempre a regra funciona estritamente visto que o custo marginal de um projeto com IA é variado e depende muito de fatores externos como tokens, uso do usuário e disponibilidade do serviço que são difíceis de prever a menos que seja usado efetivamente. --- ## Questão 4 — Gestão de Riscos e Segurança * **Legibilidade da Questão:** 96% * **Gravidade de Leitura:** Nenhuma ### 4.1 Classificação do Evento e Matriz de Riscos * **Diagrama / Elemento Visual:** * Indicou coordenadas na matriz: Probabilidade 1 (Baixa) × Impacto 2 (Alto/Crítico) -> Quadrante Médio. * **Resposta Manuscrita:** > Este evento é um problema visto que é um fato concreto e não especulação. Tal risco (seguindo a métrica da matriz P×I) teria impacto 2 pois o vazamento da chave é gravíssimo e pode acarretar na quebra do projeto e teria probabilidade 1 já que é difícil que algo tão importante como a chave passe desapercebido pelo desenvolvedor e pelo revisor, se classificando então como risco médio. ### 4.2 Resposta a Incidentes e Defesa em Profundidade * **Resposta Manuscrita:** > Como ações imediatas é necessário tirar do ar imediatamente o sistema, girar uma nova chave deletando a antiga e remover e deletar permanentemente da API e do repositório público. Já como ação preventiva é importante implementar testes que varram o repositório a cada commit procurando se há qualquer vazamento de chave para poder trancar a mesclagem do código antes mesmo de sua submissão para o repositório. ### 4.3 Modelagem de Ameaças em IA e Documentação Decisória * **Resposta Manuscrita:** > Risco de entrada: Prompt injection. > Causa: Prompt malicioso do usuário para quebrar o sistema. P: 2, I: 2. > Mitigação: Mecanismos de identificação da ocorrência da injeção para bloqueio e travamento imediato. > Contingência: Verificar sempre se a entrada possui malícia e se a saída possui comportamento fora do esperado. > Risco de saída: Alucinação. > Mitigação: Mecanismo de verificação saída gerada em relação a entrada solicitada de modo que refatore incongruências. > Para registro de decisões de segurança o ideal é usar ADR identificando os riscos explicitando causa, consequência e plano de contenção de cada risco separadamente. --- ## Questão 5 — Comunicação, Partes Interessadas e Conflitos * **Legibilidade da Questão:** 96% * **Gravidade de Leitura:** Nenhuma ### 5.1 Canais de Comunicação e Rastreabilidade Decisória * **Resposta Manuscrita:** > Síncrona: Comunicação direta e limpa, porém difícil de registrar e rastrear. > Assíncrona: Comunicação indireta mais formal, rastreável e atemporal, porém exige ciência das partes envolvidas e tempo maior. > Para decisões técnicas críticas o ideal é acertar rapidamente o plano via reuniões síncronas e, em seguida, implementar o que foi decidido registrando Issues e comentários assíncronos e rastreáveis. ### 5.2 Engajamento de Partes Interessadas (Poder × Interesse) * **Diagrama / Elemento Visual:** * **(5) Coordenação:** Monitorar * **(2, 3) Professor e Equipe:** Gerenciar de perto * **(1) Alunos:** Manter informados * **(4) Provedor API:** Manter satisfeitos * **Resposta Manuscrita:** > Para a equipe de desenvolvimento e o professor é importante manter um canal de comunicação diário via mensagens onde cada ponto relevante do projeto seja devidamente registrado de forma que garanta rastreabilidade de todo o projeto. ### 5.3 Resolução de Conflitos e Modelo de Thomas-Kilmann * **Resposta Manuscrita:** > Nesta situação, a abordagem de conflito tem que ser a de colaborar visto que ambas as partes possuem pontos que não devem ser apenas ignorados e sim debatidos de forma que todos cheguem em um consenso final e agradável. Por outro lado, evitar é impossível já que a decisão exige uma definição imediata que não pode ser prolongada e nem é possível forçar no conflito visto que ambas as partes possuem papéis fundamentais de decisão dentro do projeto e forçar algo poderia causar quebra de confiança.